Если у вас есть система хранения данных, то рано или поздно она обязательно подвергнется модернизации, так как невозможно представить развивающийся бизнес без постоянного роста вычислительных ресурсов. Карло Велтен, генеральный директор Crisp Research, на первой конференции FlashForward, состоявшейся 1 июня 2017 года в Мюнхене, рассказал о четырех главных требованиях к модернизации систем хранения, которые сделают ИТ-инфраструктуру более надежной и современной.
Но рекомендации не имеют смысла без реализации на практике, поэтому остановимся на каждой из них применительно к новейшей системе хранения данных NetApp® All Flash FAS.
Масштабируемость (Skalierbarkeit)
NetApp® All Flash FAS обладает уникальной возможностью масштабирования среди продуктов компаний, представляющих на рынке решения с флэш-памятью. Все модели All Flash FAS могут быть расширены до 24 узлов. Это позволяет добиться невероятной «сырой» емкости в 7,3 Пб, что значительно больше, чем могут предложить конкуренты сегодня или в ближайшем будущем.
Но это еще не все! 5 июня этого года NetApp представила новую прошивку ONTAP® 9.2. С ее помощью клиенты могут масштабировать свою систему хранения почти до бесконечности, используя облачное хранилище. В версии 9.2 реализована новая технология FabricPool, которая позволяет осуществлять автоматический tiering между частными и публичными облаками, перемещая холодные данные с SSD-агрегата на более медленный объектный уровень (облако Amazon S3 или СХД NetApp StorageGRID). Это повышает эффективность использования мощностей и защиту инвестиций.
Хорошим примером использования масштабирования СХД от NetApp служит кейс Европейского космического агентства, ознакомиться с которыми вы можете по данной ссылке.
Производительность и доступность (Performance and Verf?gbarkeit)
Производительность системы хранения – очень важный параметр, так как потребности бизнеса очень быстро меняются, а ИТ-инфраструктура должна им соответствовать и быть гибкой. Поэтому создание вычислительных центров на базе самых мощных из представленных на рынке СХД, таких как All Flash FAS, является очень выгодным вложением. Результаты тестов SPC-1 показывают, что All Flash FAS входит в тройку самых быстрых систем хранения, доступных на текущий момент. Она также имеет отличный показатель соотношения цены и производительности – тот же рейтинг СХД доказал, что AFF 700s имеет лучшее соотношение $/IOPS из 10 протестированных систем.
Безопасность хранения данных (Datenhoheit and Sicherheit)
Сейчас набирают популярность решения гибридного облака, но безопасное перемещение данных между узлами внутри него все еще вызывает сомнения и опасения. Для решения этой проблемы NetApp предлагает Data Fabric. С помощью технологии Data Fabric вы можете безопасно перемещать данные в облаках (частных или публичных) и управлять ими, чтобы получить все преимущества гибридной модели. Модели NetApp серии All Flash FAS могут быть интегрированы в Data Fabric для репликации, создания резервных копий и распределения данных по различным уровням систем хранения в публичном или частном облаке.
Для того чтобы узнать больше об этой технологии, ознакомьтесь с нашим информационным буклетом.
Эффективность (Effizienz)
Для повышения эффективности системы хранения используют такие технологии, как сжатие, дедупликация и экономное распределение (thin provisioning), но ONTAP теперь также позволяет делать дедупликацию на уровне агрегата (aggregate level) и уменьшать передачу избыточных данных между томами, что повышает эффективность хранения на 30%. Это важно как клиентам крупных центров обработки данных, которые ищут способы занимать меньше пространства путем оптимизации инфраструктуры, так и небольшим поставщикам услуг для сервисных провайдеров, когда платить приходится за каждый отдельный юнит. Переход на эффективную технологию флэш-памяти дает значительную экономию для клиентов независимо от их размера. ИТ-организации, которые перешли на систему хранения All Flash FAS, сократили используемую площадь от 4 до 10 раз.
All Flash FAS от NetApp удовлетворяет всем требованиям к модернизации СХД и может быть рекомендована для компаний любого уровня и масштаба.
Для более детального знакомства с решением NetApp All Flash FAS и другими системами хранения данных NetApp, предоставляемыми компанией «ИТ-ГРАД», обращайтесь в центр компетенции. Здесь вы всегда сможете задать интересующие вас вопросы и обсудить различные варианты построения ИТ-инфраструктуры.
Как пишут многие, в последнее время с виртуальным модулем VMware vCenter Server Appliance (vCSA) часто случаются проблемы. Например, вот такая ошибка появляется время от времени:
503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x0000559b1531ef80] _serverNamespace = / action = Allow _pipeName =/var/run/vmware/vpxd-webserver-pipe)
Как пишет Anthony Spiteri, зачастую эта ошибка связана с тем, что Linux-система, на базе которой работает vCSA (а именно Photon OS в vCSA 6.5), пока еще имеет достаточно ненадежную реализацию стека работы с хранилищами (в отличие от того, который есть в Windows). Поэтому при некоторых неполадках со стораджем или появлении высокой задержки (latency) сервер vCSA может "выпадать".
Ведь vCSA 6.5 имеет аж 12 файлов виртуальных дисков VMDK (раньше их было два), с которыми что-нибудь да может иногда случиться. Один из вариантов решения - проверить диски утилитой e2fsck, которая может проблем в случае 503 ошибки. Также проблема может таиться в USB-устройствах, и тогда вам поможет вот эта статья. А еще можно заглянуть вот сюда.
Может еще помочь выполнение следующих команд в консоли vCSA для перезапуска vSphere Web Client (надо будет подождать 15 минут):
Ну и не забудьте заглянуть в эту ветку форумов VMware.
Интересно, что совсем недавно компания VMware анонсировала ежемесячные обновления vCSA, что может постепенно уменьшить имеющиеся проблемы. Но пока надежность vCenter для Windows остается более проверенной штукой (по крайней мере, в плане хранилищ), поэтому пока все вокруг топят за vCSA, подумайте нужно ли именно сейчас на него переезжать.
Это Часть 3 в серии о Storage DRS. В предыдущей части мы говорили о том как создавать и удалять SDRS Anti-Affinity правила. Чтобы закрыть тему, нам осталось редактировать/реконфигурировать существующие правила. Логично предположить, что это будет функция Set-SdrsAntiAffinityRule.
Многие администраторы больших виртуальных инфраструктур VMware vSphere, в которых работают кластеры отказоустойчивых хранилищ VMware vSAN, часто задаются вопросом, какой дисковый контроллер выбрать для организации хранения на хостах ESXi.
Дункан Эппинг дает простую рекомендацию - надо брать один из самых недорогих поддерживаемых контроллеров, который имеет большую глубину очереди (Queue Depth). Например, часто в рекомендациях для vSAN можно встретить контроллер Dell H730, который является весьма дорогим устройством, если брать его на каждый сервер.
Но его не обязательно покупать, достаточно будет дискового контроллера Dell HBA 330, который и стоит дешевле, и глубину очереди имеет в 10 раз больше, чем H730 (хотя оба они соответствуют требованиям vSAN). Да, у H730 есть кэш на контроллере, но он в данном случае не требуется. Лучше использовать интерфейс NVMe для подключения отдельного SSD-кэша, не затрагивающего RAID-контроллеры (его нужно размещать как можно ближе к CPU).
Поэтому итоговая рекомендация по выбору дискового контроллера для кластеров vSAN проста - берите любое недорогое устройство из списка совместимости vSAN Compatibility Guide, но с хорошей глубиной очереди (например, HP H240), а на сэкономленные деньги отдельно организуйте кэш на базе NVMe.
На прошедшей конференции VMworld 2017 в рамках сессии "VMware Virtual Volumes Technical Deep Dive" компания VMware рассказала о технических аспектах технологии VVols, а также возможностях, которые появятся в следующей версии платформы виртуализации VMware vSphere:
Самый интересный слайд показывают в конце презентации:
Во-первых, надо отметить, что следующая версия vSphere будет иметь номер 6.7, а, во-вторых, давайте посмотрим на три фичи, которые появятся в VVols, подетальнее:
Support for Microsoft Cluster Server (MSCS) – это была одна из причин, по которой администраторы до сих пор используют RDM, а этот вариант использования не поддерживается со стороны VVols. Данная поддержка позволит расширить сферу использования технологии.
Performance parity with VMFS – в данном случае цель VMware - обеспечить высокую производительность VVols, поскольку сейчас есть промежуточный компонент Protocol Endpoint, который замедляет работу подсистемы ввода-вывода. Также будут оптимизированы такие операции как bind, соединения VASA, а также обработка метаданных томов VVols. Кстати, в целом-то VVols должна работать даже побыстрее, чем VMFS.
IPv6 support – платформа vSphere уже давно поддерживает IPv6, а сами VVols будут поддерживать IPv6 на уровне службы VASA Provider.
Поддержка NFS 4.1 и операций BIND/UNBIND/REBIND. Сейчас они делаются через VASA provider, которые идут через control path, поэтому медленные, а будут работать через Protocol Endpoint (то есть data path, что быстрее).
Будем следить за новостями о новых возможностях VMware vSphere 6.7.
Некоторые из вас знают, что, начиная с версии vSAN 6.2, стало возможно создание "тонких" (thin) файлов подкачки. В более ранних версиях vSAN было возможно создавать только reserved своп-файлы, что требовало довольно больших объемов дисковой памяти. То есть, если у машины 16 ГБ оперативной памяти, то в два раза больше будет занято и на диске под своп (32 ГБ), так как при FTT=1 (failures to tolerate) дисковые объекты дублируются в рамках кластера.
Поэтому для сред, в которых достаточно памяти у хостов, и отсутствует Memory Overcommitment, сделали параметр в настройках кластера SwapThickProvisionDisabled, позволяющий виртуальным машинам создавать тонкие файлы подкачки.
Чтобы выставить эту настройку, есть специальный скрипт PowerCLI, который применяет ее ко всем хостам ESXi кластера vSAN.
Однако выставить настройку недостаточно - ведь, чтобы файлы подкачки стали тонкими, то есть пересоздались, надо перезагрузить (выключить и включить) виртуальные машины с толстыми swap-файлами. Найти такие машины позволит вот этот Python-сценарий. Ну а дальше уже перезагрузите машины по списку - это позволит вам сэкономить значительный объем дискового пространства кластера.
Несмотря на растущую популярность технологии VMware vSAN, большинство крупных предприятий по-прежнему частично или полностью продолжают работать с общими хранилищами (shared storage). Есть достаточно PowerCLI командлетов для конфигурирования большинства аспектов HA/DRS кластеров, однако для SDRS кластеров выбор не велик.
Весной этого года вышло обновление решения для создания отказоустойчивых кластеров для виртуальных машин на платформе vSphere - VMware vSAN 6.6. Прошлая версия продукта Virtual SAN 6.5 вышла еще осенью 2016 года, и vSAN 6.6 заметно продвинулся в плане функционала. Но, оказывается, это решение стало еще и существенно лучше в плане производительности. И на эту тему есть полезный документ "vSAN 6.6 Performance Improvements", описывающий результаты тестирования обеих версий продукта.
Для тестов использовалось одинаковое оборудование (кластер All-Flash) и 3 типа симуляции рабочей нагрузки:
Random Read
Random Write
Mixed random Read/Write (70/30%)
Посмотрим на графики, показывающие улучшения в различных аспектах:
Большое рабочее множество данных (Large Working Set)
Это самый нагрузочный вариант использования системы хранения, когда на нее идут длинные и непрерывные операции записи, иногда перемежающиеся операциями чтения.
Так выглядит суммаризованный график улучшения по числу IOPS для трех типов нагрузок и различных уровнях RAID:
Вот так выглядит уменьшение задержек при обращении к дискам (Latency). Чем ниже столбик - тем сильнее уменьшилась задержка:
Так выглядит отдельный график по IOPS для типа нагрузки 70% чтения и 30% записи:
Так выглядит Latency для этого типа нагрузки:
IOPS для Random Writes:
Latency для Random Writes:
Малое рабочее множество данных (Small Working Set)
Этот вариант использования хранилища меньше зависит от аппаратных особенностей и больше способен показать улучшения, сделанные в программных компонентах. Несмотря на то, что он не встречается в чистом виде (как впрочем и Large Working Set), малые рабочие множества встречаются в среде, где работают много небольших задач одновременно, обращения которых к хранилищам перемешиваются в потоке ввода-вывода.
Так выглядит суммаризованный график улучшения по числу IOPS для трех типов нагрузок и различных уровнях RAID (заметьте, что процент улучшений здесь значительно выше, чем для Large Working Set):
Вот так выглядит уменьшение задержек при обращении к дискам (Latency). Чем ниже столбик - тем сильнее уменьшилась задержка (также улучшения более существенны, чем для Large Working Set):
Так выглядит отдельный график по IOPS для типа нагрузки 70% чтения и 30% записи:
Так выглядит Latency для этого типа нагрузки:
IOPS для Random Writes:
Latency для Random Writes:
В целом, мы видим, что по всем параметрам и для всех аспектов (рабочее множество, тип нагрузки, уровень RAID) решение vSAN 6.6 обходит своего предшественника (а в некоторых случаях - весьма существенно).
Многие из вас знакомы с решением номер 1 на рынке для создания программных отказоустойчивых кластеров хранилищ StaWind Virtual SAN. За последнее время продукты компании сделали большой шаг вперед, в том числе в плане интерфейсов, и сегодня мы рассмотрим процесс установки и начала использования централизованного средства мониторинга кластеров Storage Spaces Direct - StarWind Manager. Это полностью бесплатный продукт и доступен сейчас в статусе Preview.
Таги: StarWind, Manager, Storage, Microsoft, Spaces, S2D, Virtual SAN
Компания VMware сделала доступной небольшую онлайн-утилиту для сайзинга серверов хранения виртуальных машин, работающих в отказоустойчивых кластерах хранилищ - VMware vSAN Sizer. Также она производит подбор необходимых конфигураций серверов (для расчетов принимается, что все узлы будут использовать конфигурацию All-Flash SSD).
От пользователя требуется лишь ввести число виртуальных машин и объем их виртуальных дисков (пока указано, что для расчета используется некий усредненный тип нагрузки, возможно, в будущем будут добавлены еще профили нагрузок ВМ).
На первом этапе нам показывают, сколько нужно серверов и неразмеченного хранилища (Raw Storage):
Ниже мы видим технические характеристики каждого из хостов ESXi:
Ну а в рамках дополнительной информации можно вывести параметры дисковых групп (кэш и емкость хранения). В моем случае это 2 дисковых группы:
В утилите VMware vSAN Sizer расположена ссылка на расширенную версию, которая доступна для партнеров, но когда я зашел под партнерским аккаунтом, то увидел там только пустую белую страницу с шапкой меню.
В статье о новой версии продукта для организации отказоустойчивых кластеров хранилищ vSAN 6.6 мы писали о том, что появилась утилита Configuration Assist, созданная для того, чтобы после установки кластера правильно сконфигурировать среду vSphere, чтобы все работало корректно и соответствовало необходимой конфигурации платформы.
Первоначальные задачи по настройке кластера, развертываемого через Easy Install или vSphere Web Client, включают в себя настройку порта VMkernel для трафика vSAN, выделение дисков и т.п. Как часть процесса установки, мастер vSAN Setup Wizard заботится о таких специфических вещах, как дедупликация и компрессия, число узлов, растянутый это будет кластер или нет, но не заботится об общих настройках среды VMware vSphere.
Для этого и был сделан раздел vSAN Configuration Assist, который вам поможет со следующими операциями:
Настройка высокой доступности vSphere High Availability.
Конфигурация vSphere Distributed Switch для трафика vSAN.
Настройка vMotion для ВМ.
Позволит убедиться в том, что все доступные накопители используются для кластера.
Есть средства конфигурации хостового контроллера.
Есть необходимая версия микрокода (firmware) хостового контроллера.
Все эти задачи можно выполнить из различных разделов vSphere Web Client, но мастер Configuration Assist позволяет сделать это в единой точке интерфейса как часть рабочего процесса по конфигурации кластера vSAN. Ну и важный момент, что это своего рода чеклист необходимых задач постконфигурации кластера хранилищ.
Вот как это примерно делается (приведен пример, как настроить для vSAN или vMotion интерфейсы VMKernel):
Выделение дисков под кластер идет в момент его развертывания, но после установки это уже можно сделать через Configuration Assist:
Конечно же, необходима настройка vSphere HA/DRS:
Ну и последнее, но не менее важное - утилита позволяет вам обновлять микрокод узлов различных OEM-производителей, таких как Dell, Lenovo, Fujitsu и SuperMicro:
Поэтому первым делом после развертывания кластера vSAN идите в раздел Configuration Assist клиента Web Client.
Таги: VMware, vSAN, vNetwork, VMachines, Storage, HA, Web Client
Оказывается, еще в начале мая компания HP совместно с VMware выпустила кастомизированный образ гипервизора vSphere - HPE Customized ESXi May 2017, предназначенного для установки на серверы HP.
Этот релиз для многих администраторов является важным событием, так как прошлый кастомизированный образ HPE Custom ESXi от ноября 2016 года содержал в себе некоторые проблемы, касающиеся драйверов и работы с хранилищами (в частности, наблюдалась низкая скорость записи на локальные диски). Возможно, в этом релизе данные проблемы решены, по крайней мере новый набор драйверов должен улучшить некоторые вещи.
HPE Customized ESXi May 2017 доступен для скачивания по этой ссылке. Предыдущие образы (для более ранних версий гипервизора) можно также скачать с сайта VMware по этим ссылкам:
Номера билдов и их содержимое приведены вот в этом документе HPE (там же есть ссылки на соответствующие драйвера и офлайн бандлы ESXi). Ну а руководство по кастомизированным билдам HPE Custom ESXi находится вот тут.
Многим из вас известен продукт для организации отказоустойчивых кластеров хранилищ под виртуальную инфраструктуруру StarWind Virtual SAN. Он выпускается уже в течение многих лет и давно зарекомендовал себя как лучшее в отрасли решение для создания программных хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Его основные возможности приведены тут и вот тут. А сегодня мы расскажем о том, что продуктом и всеми его функциями стало можно пользоваться фактически бесплатно!
Многие пользователи небольших виртуальных инфраструктур ищут надежные решения для организации программных хранилищ, при этом им бы не хотелось покупать отдельную лицензию на Windows Server под узлы хранения.
Специально для них компания StarWind, известная своим продуктом Virtual SAN, позволяющим организовать отказоустойчивые кластеры хранилищ, создала виртуальный модуль StarWind Virtual Storage Appliance (VSA) на базе Linux.
StarWind VSA представляет собой полностью готовую к импорту в вашу виртуальную среду виртуальную машину, реализующую все необходимые сервисы Virtual SAN. Развертывается она буквально в пару кликов, а далее управляется через удобную веб-консоль (StarWind Web console).
Чтобы узнать больше о возможностях продукта и вживую увидеть его демонстрацию (а также позадавать вопросы на русском языке) - регистрируйтесь на вебинар. Скачать StarWind Virtual Storage Appliance можно по этой ссылке.
Те из вас, кто следят за обновлениями решения для организации кластеров хранилищ VMware vSAN, знают, что в версии vSAN 6.6 появилась возможность обеспечивать избыточность на уровне локального сайта и на уровне двух площадок растянутого кластера (stretched cluster) в то же самое время.
Напомним, что для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1 (на обычных дисках), а также RAID-5 или RAID-6 (для архитектуры All-Flash).
Это, кстати, означает, что при полном отказе одного из сайтов растянутого кластера, виртуальные машины выжившего сайта все еще будут защищены на уровне отдельных хостов или виртуальных дисков. Единственное, что для этого компонент Witness должен быть доступен. Ну и, само собой, при отказах дисков/хостов внутри площадки виртуальные машины также будут защищены в соответствии с политикой SFTT.
Все это вызывает логичный вопрос - а как планировать емкость обеих площадок, на которых работает vSAN? Кстати, нельзя называть эти площадки основной и резервной, так как они работают в режиме Active-Active.
Традиционно, до введения политик избыточности на уровне каждой из площадок, планирование емкости было простым - надо было просто удвоить исходную емкость одной площадки. В vSAN 6.2 появилась не только защита RIAD-1 (mirroring), но и RIAD-5/6 (erasure coding), что позволяет в рамках растянутых кластеров организовать различные схемы размещения данных. Отметим, что алгоритм erasure coding между площадками пока не реализуем ввиду ограничений на уровне домена отказа (Fault Domain). Поэтому между площадками - только Mirroring.
Учитывая все это, в VMware сделали единую табличку, которая поможет вам при планировании емкостей инфраструктуры vSAN как для растянутого кластера, так и для кластера в рамках одной площадки:
В поле PFTT для растянутых кластеров мы видим 1, а для обычных 0. FTM (Failure Tolerance Mode) - это режим обеспечения отказоустойчивости на уровне каждого из сайтов. Напомним, что для обычных дисков он может быть только Mirroring, а для All-Flash архитектур - Mirroring или Erasure Coding.
SFTT определяет число отказов дисковых объектов внутри площадки, которое сможет перенести каждая из площадок вашего растянутого кластера.
Таким образом, если вы организуете растянутый кластер хранилищ на базе архитектуры All-Flash со средствами защиты Erasure Coding в рамках площадки и Mirroring между площадками, то вам потребуется 266% исходной дисковой емкости виртуальных машин (ее можно скорректировать на экономию от Thin Provisioning).
Ну а если вы будете использовать обычные диски и защиту Mirroring как внутри площадки, так и между площадками - вам потребуется 400% исходной емкости.
В довершение нужно обязательно отметить, что администратор не может контролировать, где будут размещаться дисковые объекты ВМ в пределах одного сайта (то есть не получится обеспечить распределение дублированных копий объектов на уровне серверных стоек одной площадки).
В феврале мы писали о средстве IOInsight, которое позволяет детально взглянуть на характеристики взаимодействия виртуальных машин с хранилищами и провести анализ метрик ввода-вывода на уровне отдельных VMDK-дисков.
На днях на сайте проекта VMware Labs появилось обновление этого виртуального модуля - IOInsight 1.1.
Давайте посмотрим на новые возможности последней версии:
Утилита командной строки для установки статического IP-адреса или DHCP.
Опция для установки NTP-севреров.
Опция в интерфейсе, позволяющая настроить отсылку логов и результатов вывода IOInsight разработчикам для последующего решения проблем.
Вот какие ошибки были исправлены и улучшения добавлены:
На интересную проблему обратил внимание Anthony Spiteri в своем блоге - у него после развертывания платформы VMware ESXi 6.5 на сервере с SSD-дисками ISO-образ Windows 2016 полчаса заливался на датастор (интересно, что нам некоторые читатели писали о подобной проблеме). Потом он создал новую виртуальную машину и поставил устанавливаться Windows, а ESXTOP показывал скорость записи 10-20 МБ/с, в то время как она должна была быть на уровне 400-500 МБ/с.
Он стал ковырять проблему дальше и раскопал драйвер, который используется для SATA-контроллера:
Далее он проверил, какие драйверы подсистемы хранения сейчас загружены и используются. Оказалось их два: приведенный выше драйвер и нативный драйвер VMware:
Как видим, он затем вывел список системных модулей и увидел, что нативный драйвер отключен. После того, как он перезагрузил хост ESXi, все стало летать - гостевая ОС установилась за 5 минут, а тесты внутри ВМ показали высокую скорость чтения-записи.
HyperConverged Appliance - это собственная гиперконвергентная платформа StarWind для организации хранилищ, которая может быть использована самыми различными способами в инфраструктурах на базе различных гипервизоров. Больше об этом решении можно узнать тут и тут.
Посмотрите запись вебинара, чтобы узнать, как этот программно-аппаратный комплекс на базе GRID-архитектуры позволит вам с максимальной эффективностью размещать виртуальные машины любых гипервизоров и управлять инфраструктурой хранения из единой точки.
Как некоторые знают, в VMware vSphere 6.5 появилась (а точнее вернулась снова) возможность Automatic VMFS UNMAP - возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически. Работает UNMAP только для "тонких" (Thin Provisioned) LUN, на которых размещаются тома VMFS.
Из GUI vSphere Web Client можно управлять только UNMAP'ом для томов VMFS 6, для пятой версии файловой системы это нужно делать вручную с помощью ESXCLI. Кроме того, механизм UNMAP работает в асинхронном режиме, а иногда хочется почистить хранилища от неиспользуемых блоков прямо сейчас.
Поэтому весьма кстати, что на сайте EnterpriseDaddy обнаружился полезный PowerCLI-скрипт, который возвращает дисковое пространство в LUN для заданного хранилища хоста ESXi.
Эта функция принимает на вход имя хоста ESXi и Datastore, а также отключает таймаут на исполнение операций, так как возврат дискового пространства LUN может занять часы.
Function Perform-VMFSUnmap {
[CmdletBinding()]
param(
[Parameter(
Mandatory=$true)]
[String[]]$Datastore,
[String]$ESXiHost
)
Set-PowerCLIConfiguration -WebOperationTimeoutSeconds -1 -Scope Session -Confirm:$false
$ESXHost = Get-VMHost $ESXiHost
$DatastoreName = Get-Datastore $Datastore
Write-Host 'Using ESXCLI and connecting to $VMHost' -ForegroundColor Green
$esxcli = Get-EsxCli -VMHost $ESXHost
Write-Host 'Unmapping $Datastore on $VMHost' -ForegroundColor Green
$esxcli.storage.vmfs.unmap($null,$DatastoreName,$null)
}
Гостевой пост компании ИТ-ГРАД. Этой статьей мы продолжим традиционную рубрику в стиле unboxing и уделим внимание системе хранения данных нового поколения в лице NetApp AFF A300, презентованной в конце сентября прошлого года во время ежегодной конференции для партнеров и заказчиков NetApp Insight. Пришедшая на смену AFF8040 и AFF8060 новая all-flash-система успела порадовать техническими характеристиками и успешно разместилась на облачной площадке «ИТ-ГРАД»...
Многие пользователи применяют платформу XenServer ввиду ее бесплатности и легковесности, но сталкиваются с проблемами обеспечения высокой доступности хранилищ на случай сбоев оборудования. В этой сфере могут помочь программные решения StarWind Virtual SAN, которые позволяют организовать HA-хранилище с синхронизацией данных на нескольких узлах и высокоскоростной доступ на базе протокола iSCSI.
В документе описана HA-конфигурация серверов - вам потребуется как минимум 2 сервера с XenServer/XenCenter для запуска виртуальных машин и 2 сервера для организации кластера хранилищ StarWind HA, они могут быть физическими или виртуальными. То есть, всего нужно будет 2-4 физических сервера.
Также в документе рассмотрена пошаговая конфигурация узлов StarWind и настройка сетевого взаимодействия в консоли XenCenter для организации канала синхронизации между узлами хранилищ. Кроме того, вы узнаете, как настроить iSCSI Initiator в XenServer и механизм доступа по нескольким путям (Multipathing).
Таги: StarWind, iSCSI, XenServer, Storage, Virtual SAN
На сайте проекта VMware Labs появилась действительно достойная внимания утилита - IOInsight, доступная в виде готового к развертыванию виртуального модуля на платформе vSphere. Она позволяет детально взглянуть на характеристики взаимодействия виртуальных машин с хранилищами и провести анализ метрик ввода-вывода на уровне отдельных VMDK-дисков.
Все это позволит принимать решения о тюнинге производительности и планировании емкостей по пропускной способности на основе данных, выводимых в графиках и отчетах:
В решении каких проблем может помочь IOInsight:
Самостоятельная оптимизация производительности и планирование хранилищ пользователями vSphere.
Отчет из IOInsight может помочь при обращении в техподдержку VMware, что ускорит решение проблемы.
Сотрудники VMware Engineering могут подсказать решения по оптимизации ваших продуктов.
IOInsight собирает все метрики с хостов ESXi по вводу-выводу и представляет их в агрегированном виде для анализа. При этом в отчете IOInsight нет никакой чувствительной информации о приложениях и системах, так что можно смело отдавать его сотрудникам VMware.
Кроме того, предполагается, что администраторы и разработчики сами будут писать плагины к IOInsight, поскольку в состав решения включены SDK и development guide (как видите на картинке, два плагина уже есть). Руководство для обычных пользователей доступно вот тут.
Лучшие практики по использованию IOInsight:
2-4 виртуальных процессора на виртуальный модуль (vCPU)
2 ГБ и более оперативной памяти
Желательно разместить IOInsight в той же сети, что и хосты, которые планируется мониторить
Нужно выбирать не более 8 VMDK, чтобы не было слишком высокой нагрузки
Рекомендуемый период анализа данных - 10-30 минут
Cache Simulation analyzer создает нагрузку на процессор, поэтому его нужно запускать для 1 или 2 симулируемых конфигураций кэша (не более)
Утилита IOInsight работает, начиная с версии VMware vSphere 5.5, а скачать ее можно по этой ссылке.
В январе компания StarWind проводила вебинар о виртуальном модуле StarWind VSA на базе Linux, который позволит вам создавать программные хранилища iSCSI/NFS для ваших виртуальных машин.
Сейчас стала доступна запись этого вебинара, где Богдан рассказывает о том, для чего предназначен StarWind VSA и наглядно в консоли показывает, каким образом с ним нужно работать:
Ожидается, что продукт StarWind VSA for Linux будет доступен в течение пары месяцев.
Вебинар пройдет 9 февраля в 19-00 по московскому времени.
Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
Помимо этого, LSFS имеет следующие полезные функции:
Встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут).
Поддержка непрерывной дефрагментации (она идет в фоне).
Дедупликация данных "на лету" (то есть, перед записью на диск).
Улучшения производительности за счет комбинирования операций записи.
Поддержка overprovisioning.
Использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов.
В новом билде StarWind Virtual SAN у LSFS появилось несколько новых экспериментальных возможностей, которые позволят вам получить больше от этой технологии:
Передача операций по работе с метаданными на SSD (что снижает требования к RAM).
Оптимизация производительности операций чтения и записи, что сокращает время на них до 4-5 раз.
Напомним, что у компании StarWind есть аппаратно-программные решения для создания готовых к эксплуатации кластеров хранилищ под виртуальные машины - StarWind Storage Appliance. Также есть и чисто программное решение - StarWind Virtual Storage Appliance (VSA), который представляет собой готовый виртуальный модуль с сервисами хранилищ.
Ну а обо всем, что касается StarWind Storage Appliance, можно узнать на специальном сайте - https://www.starwindstorageappliance.com/, где собрано множество различных материалов об этих модулях.
На сайте вы узнаете, как из дорогой инфраструктуры слева получить значительно менее затратную инфраструктуру справа, повысив ее гибкость и не потеряв в производительности:
Компания StarWind выпускает новый продукт - виртуальный модуль для создания программных хранилищ на базе ОС Linux (StarWind Virtual Storage Appliance, VSA), который будет работать на любом гипервизоре в виде готовой к использованию виртуальной машины.
Вебинар пройдет в этот четверг, 19 января в 17-00 по московскому времени. Обратите внимание, что у StarWind новый спикер - Алекс Быковский (вопросы можно задавать на русском языке).
К сожалению, нету «прямого» пути для миграции шаблонов (VM Templates) с одного датастора на другой (т.н. процедура Storage VMotion). Представляю вашему вниманию функцию Move-Template2Datastore из моего PowerCLI Vi-Module модуля. Функция принимает объект(ы) Template и один объект датастора и производит 3 действия...
Компания VMware сделала доступным весьма полезный ресурс StorageHub, который будет интересен всем тем, кто хочет узнать все об использовании виртуальных и физических хранилищ под виртуальные машины на базе платформы VMware vSphere. Также на StorageHub есть документы и об инструментах обеспечивающих доступность виртуальных сервисов (например, VMware Site Recovery Manager):
Недавно компания VMware выпустила новую версию платформы vSphere 6.5, о новых возможностях которой мы писали вот тут. Между тем, в плане хранилищ было сделано несколько важных улучшений, которые заслуживают отдельного поста. Большинство из этого реализуемо только на базе файловой системы VMFS 6.0, которая также появилась в vSphere 6.5.
1. Возврат дискового пространства хранилищу (Storage UNMAP).
Эта возможность была еще в VMware ESXi 5.0, но пропала по некоторым техническим причинам в следующих версиях. Теперь она полноценно была реализована в двух вариантах:
Automatic UNMAP
Поддержка Linux-based In-Guest UNMAP
Automatic UNMAP - это возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически.
Для работы этой возможности вам понадобятся:
ESXi 6.5+
vCenter 6.5+
VMFS 6
Дисковый массив с поддержкой UNMAP
Если мы в настройках хранилища откроем вкладку Configure:
И далее нажмем Edit в разделе Space Reclamation Priority, то мы увидим вот такую настройку:
Здесь устанавливается приоритет, в соответствии с которым свободные блоки будут автоматически возвращены к LUN. Надо понимать, что UNMAP - это асинхронный процесс, который выполняет специальный crawler, потому и задается его приоритет. Понятное дело, что если задать высокий приоритет, то создастся дополнительная нагрузка на хранилища.
Кстати, для немедленного возврата дискового пространства можно воспользоваться командой esxcli storage vmfs unmap.
Поддержка Linux-based In-Guest UNMAP в vSphere 6.5 появилась впервые. Для ее работы нужна поддержка со стороны гостевой ОС Linux и ее файловой системы. Ну и работает это все только для тонких (thin) дисков.
Работает она не полностью автоматически, а запустить ее можно тремя способами:
Смонтировать файловую систему с опцией discard. Это будет возвращать простраство автоматически, когда будут удаляться файлы.
Выполнение команды sg_unmap. Это запустит механизм UNMAP для выбранных LBA.
Выполнение fstrim. Это вызовет команды trim, которые ESXi конвертирует в операции механизма UNMAP на уровне слоя vSCSI.
2. Функция Thin Hot Extend.
Это очень полезная штука была несколько ранее - она позволяла на горячую увеличить размер тонкого диска.
Вся загвоздка была в том, что диск можно было увеличить только до 2 ТБ, иначе возникала вот такая ошибка:
Теперь же можно задавать виртуальный диск любого размера.
3. Поддержка 4K-дисков в режиме 512e.
Теперь расширенный формат дисковых устройств 4K поддерживается со стороны vSphere 6.5, однако в режиме эмуляции 512e (то есть для 4к-девайсов эмулируются 512-байтные сектора). Такая же поддержка есть и в VMware Virtual SAN 6.5.
Полная поддержка 4k-устройств в нативном режиме ожидается в ближайшем будущем.
4. Поддержка до 512 устройств и 2000 путей.
Ранее платформа vSphere поддерживала 256 устройств и 1024 пути к одному хранилищу. И некоторые умудрялись упираться в лимиты, поэтому для таких клиентов и было сделано увеличение максимумов.
5. Увеличение лимита CBRC (он же View Storage Accelerator).
Про механизм кэширования Content Based Read Cache (CBRC) мы писали вот тут. Он позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК за счет кэширования в оперативной памяти хоста VMware ESXi.
Ранее он был ограничен объемом в 2 ГБ, а теперь увеличился до 32 ГБ:
Теперь в vSphere 6.5 есть механизм для переподписки так называемых unresolved volumes, то есть томов, которые отвязались от основного по каким-то причинам, и теперь их метаданные являются не соответствующими текущей структуре файловой системы. Так, например, бывает в процессе резервного копирования, когда остается какой-нибудь повисший на диске снапшот, который не видно из GUI клиента vSphere.
В этом плане была проделана существенная работа и сделано множество улучшений, о которых можно прочитать тут.
Это основные, но не все улучшения VMware vSphere 6.5 в плане хранилищ, а если хочется узнать обо всех, то почитайте документ "vSphere 6.5 Storage", где очень много всего интересного.
В этом документе описывается подход компании StarWind к работе с кэшем уровня L1 (RAM buffer) и L2 (SSD-кэш), а также подробно раскрываются методики кэширования Write-Back и Write-Through, о которых мы также писали ранее.
Кэширование StarWind для уровней L1 и L2 основывается на одном механизме, поэтому множество вещей из документа вполне применимы к обоим уровням кэширования. Данные из кэша, кстати, удаляются в соответствии с политикой LRU (least recently used), то есть наименее используемые данные стираются из кэша первыми.
Остальные интересные технические вещи о кэшировании StarWind (которых немало) читайте в документе.
RSS
